Security-By-Contract for the Future Internet

With the advent of the next generation java servlet on the smartcard, the Future Internet will be composed by web servers and clients silently yet busily running on high end smart cards in our phones and our wallets. In this brave new world we can no longer accept the current security model where programs can be downloaded on our machines just because they are vaguely “trusted”. We want to know what they do in more precise details. We claim that the Future Internet needs the notion of security-by-contract: In a nutshell, a contract describes the security relevant interactions that the smart internet application could have with the smart devices hosting them. Compliance with contracts should verified at development time, checked at depolyment time and contracts should be accepted by the platform before deployment and possibly their enforcement guaranteed, for instance by in-line monitoring. In this paper we describe the challenges that must be met in order to develop a security-by-contract framework for the Future Internet and how security research can be changed by it. 1 The End of Trust in the Web The World Wide Web evolved rapidly in 90’s with a highlight in 1995 when the Java Applet enabled secure mobile code for the Web. In this millennium the notion of the Web has changed: rather than a network, the Web has become a platform where people migrate desktop applications. We have richer applications such as WebMail, Social Web sites, Mashups, Web 2.0 applications, etc. this is further supported by technologies such as Asynchronous JavaScript and XML (AJAX), .NET, XML, SOAP (Web Services). Fact of Life 1 The security model of the current version of the web is based on a simple assumption: the good guys develop their .NET or Java application, expose it on the web, and then spend the rest of their life letting other good guys using it while stopping bad guys from misusing it. The business trend of outsourcing processes [16] or the construction of virtual organizations [18] have slightly complicated this initially simple picture. Now running a “service” means that different service (sub)components can be dynamically chosen and different partners are chosen to offer those (sub)services. ? Research partly supported by the Projects EU-FP6-IST-STREP-S3MS, EU-FP6-IPSENSORIA, and EU-FP7-IP-MASTER. We would like to thank Eric Vetillard for pointing to us the domain of Next Generation Java Card as the Challenge for the Future Internet. Hence we need different trust establishment mechanisms (see e.g. [23, 22]). A large part of the WS security standards are geared to solve some of these problems: WSFederation defines the mechanisms for federating trust; WS-Trust enables security token interoperability; WS-Security [3] covers the low level details such as message content integrity and confidentiality; WS-Security Policy [9] details lower level security policies . Still, the assumption is the same: the application developer and the platform owner are on the same side. Traditional books on secure coding [20] or the .NET security handbook [24] are pervaded by this assumption. Unfortunately, this assumption is no longer true for the brave new world of Web 2.0 and the Future Internet. Already now a user downloads a multitude of communicating applications ranging from P2P clients to desktop search engines, each of them ploughing through the user’s platform, and springing back with services from and to the rest of the world. Most of these applications will be developed by people and companies that a lay user had never known they existed (at least before downloading the application). It looks like we are simply back to the good old security model of Java applets [15] and good confinement would do the job. Nothing could be more wrong: applets are light pieces of code that would not need access to our platform. Indeed, to deal with the untrusted code either .NET [24] or Java [15] can exploit the mechanism of permissions. Permissions are assigned to enable execution of potentially dangerous or costly functionality, such as starting various types of connections. The drawback of permissions is that after assigning a permission the user has very limited control over how the permission is used. Conditional permissions that allow and forbid use of the functionality depending on such factors as bandwidth or the previous actions of the application itself (e.g. access to sensitive files) are also out of reach. Once again the consequence is that either applications are sandboxed (and thus can do almost nothing), or the user decided that they are trusted and then they can do almost everything. The mechanism of signed assemblies from trusted third parties does not solve the problem either. Fact of Life 2 Currently a signature on a piece of code only means that the application comes from the software factory of the signatory, but there is no clear definition of what guarantees it offers. It essentially binds the software with nothing. Loosely speaking, the mobile software deployment process is identical to the hiring process of the aristocratic armies. In order to hire an officer you don’t ask for his CV, you don’t stipulate a contract with him and set targets. You just ask for his father’s name and depending on that name you make him lieutenant, major or general. You grant him the privileges of the rank and trust that he’ll not betray the name of the family. The (once) enthusiast installers of UK Channel 4 on demand services 4oD [1] might tell a different story [29]. What is best than download a client that allows you to see almost free movies from your favorite TV channel? After all you are downloading from a reputable and trusted broadcaster. It is not shady software from a hacker web site. Only in the fine print of the legal terms of use (nowhere in the FAQs and only visible after a long scrolling down of legalese) you find something you most likely would like to know beforehand (extracted from the web site on 31st of July 2008): If you download Content to your computer, during the License Period, we may upload this from your computer (using part of your upstream bandwidth) for the purpose of transferring Content to other users of the Service. Please contact your Internet Service Provider (”ISP”) if you have any queries on this. As one of the many unfortunate users of the system noticed [29], there is no need of contacting your ISP. They will contact you pretty soon and will not be pleasant. . . Fact of Life 3 We end up in a stale-mate. We built our security models on the assumption that we could trust the vendors (or at least some of them). The examples from reputable companies such as Channel 4 (or BBC, Sky TV etc.) show that this is no longer possible. Still we really really want to download a lot of software. 2 The Smart(Card) Future of the Web The model that we have described above is essentially the web of the personal computers. We, as world-wide consumer3, accept the idea that PC applications fails, that PC are ridden with viruses, spyware and so on. So we do not consider this a major threat Fact of Life 4 None of the users complaining about 4oD [29] have considered their PC or their Web platform “broken” because it allowed other people to make use of it. They did not consider returning their PC for repair. They considered themselves being gullible users ripped off by an untrusted vendor. There is another domain at the opposite side of the psychological spectrum: smartcard technology. This technology enjoyed worldwide deployment in 90’s with Java Card Applets and their strict security confinement. At the beginning of the millennium, many applications such as large SIM cards, emerging security and identity management businesses are implemented on smart-cards to address mobile devices security challenges [19]. Still, smart-cards have essentially led a sheltered life from the Web problems we have described. When used in mobile phones they just acted as authenticator and withdrawn from the picture immediately. (Un)fortunately, the smartcard technology evolved with larger memories, USB and TCP/IP support and the development of the Next-Generation Java Card platform with Servlet engine. This latter technology is a full fledged Java platform for embedded Web applications and opens new Web 2.0 opportunities such as NG Java Card Web 2.0 Applications. It can also serve as alternative to personalized applications on remote servers so that personal data no longer needs to transmitted to remote third-parties. Prediction 1 The Future Internet will be composed by those embedded Java Card Platforms running on high end smart cards in our phones and our wallets, each of them connecting to the internet and performing secure transactions with distributed servers and desktop browsers without complicated middleware or special purpose readers. We still want to download a huge amount of software on our phones but there is a huge psychological difference from a consumer perspective. 3 We should distinguish between the computer scientist or security expert and the computer, even if savvy, user. Fact of Life 5 If our PC is sluggish in responding, we did something wrong or downloaded the wrong software, if our phone is sluggish, it is broken. Idea 1 In the realm of next generation Java card platforms we cannot just download a software without knowing what it does. The smart card web platform must have a way to check what is downloading. 3 Security by Contract for the Smart Future Internet In the past millennium Sekar et al. [32] have proposed the notion of Model Carrying Code (MCC) as the seminal work on which our research agenda for the Smart Future Internet is based. MCC requires the code producer to establish a model regarding the safety of mobile code which captures the security-relevant behavior of the code. The code consumers checks their policies against the model associated with untrusted code to determine if this code will violate their policy. The major limitation was that MCC had not fully developed the whole lifecycle and had limited itself to finite state automata which are too simple to describe realistic policies. Even a simple, basic policy such as “Only access url starting with http” could not be addressed. The Security-by-Contract (S×C) framework that we have developed for mobile code [11, 10] builds upon the MCC seminal idea to address the trust relationship problem of the current security models in which a digital signature binds a contract with nothing. Idea 2 In S×C we augment mobile code with a claim on its security behavior (an application’s contract) that could be matched against a mobile platform’s policy before downloading the code. A digital signature does not just certify the origin of the code but also bind together the code with a contract with the main goal to provide a semantics for digital signatures on mobile code. This framework is a step in the transition from trusted code to trustworthy code. This idea is nice but we must develop it fully in order to really make a significant advance over the initial intuition from model carrying code. So we should consider the full lifecycle. A contract should be negotiated and enforced during development, at time of delivery and loading, and during execution of the application by the mobile platform. Figure 1 summarizes the phases of the application/service life-cycle in which the contract-based security paradigm should be present. At development time the mobile code developers are responsible for providing a description of the security behavior that their code finally provides. Such a code might also undergo a formal certification process by the developer’s own company, the smart card provider, a mobile phone operator, or any other third party for which the application has been developed. By using suitable techniques such as static analysis, monitor in-lining, or general theorem proving, the code is certified to comply with the developer’s contract. Subsequently, the code and the security claims are sealed together with the evidence for compliance (either a digital signature or a proof) and shipped for deployment. Fig. 1: Application/Service Life-Cycle At deployment time, the target platform follows a workflow similar to the one depicted in Fig.2 (see also [35]). First, it checks that the evidence is correct. Such evidence can be a trusted signature as in standard mobile applications [40]. An alternative evidence can be a proof that the code satisfies the contract (and then one can use PCC techniques to check it [28]). Once we have evidence that the contract is trustworthy, the platform checks, that the claimed policy is compliant with the policy that our platform wants to enforce. If it is, then the application can be run without further ado. This may be a significant saving from in-lining a security monitor. At run-time we might want to decide to still monitor the application. Then, as with vaccination, we might decide to inline a number of checks into the application so that any undesired behavior can be immediately stopped or corrected. 4 What is a Contract for the Smart Future Internet? The first challenge that we must address is finding an appropriate language for defining contracts and policies. Definition 1. A contract is a formal complete and correct specification of the behavior of an application for what concerns relevant security actions (Virtual Machine API Calls,Web Messages etc). By signing the code the developer certifies that the code complies with the stated claims on its security-relevant behavior. On the other side we can see that users and mobile phone operators are interested that all codes that are deployed on their platform are secure. In other words they must declare their security policy: